Developer CD Series 1993…stman Always Clicks Twice/ADC Developer CD (1993-01) (''The Postman Always Clicks Twice'')_iso/Dev.CD 199301.iso/Development Platforms/CSMP Digests/csmp-v1-047.txt

Text File | 1992-11-18 | 43.6 KB | 1,126 lines | [TEXT/MPS ]

C.S.M.P. Digest             Fri, 10 Apr 92       Volume 1 : Issue 47

Today's Topics:

    680x0 Caches
    sprintf weirdness
    Questions on THINK C Objects and Interrupts
    code overflow in Think C
    "Procedural" (was Re: Suggestion to the Developers of Think C)
    Opening documents while the creator prog is running?
    Help! Declaring big array
    Looking for B-Tree/Data base source
    Letting Sleeping Powerbooks Lie
    MPW C++ & Zortech C++ Info Wanted
    CTB/System 7 popup menu bug


The Comp.Sys.Mac.Programmer Digest is moderated by Michael A. Kelly.

These digests are available (by using FTP, account anonymous, your email
address as password) in the pub/mac/csmp-digest directory on ftp.cs.uoregon.
edu.  This is also the home of the comp.sys.mac.programmer Frequently Asked
Questions list.

These digests are also available via email.  Just send a note saying that you
want to be on the digest mailing list to [e-mail], and you will
automatically receive each new digest as it is created.

The articles in these digests are taken directly from comp.sys.mac.programmer.
They are not edited; all articles included in this digest are in their original
posted form.  The only articles that are -not- included in these digests are
those which didn't receive any replies (except those that give information
rather than ask a question).  All replies to each article are concatenated
onto the original article in the order in which they were received.  Article
threads are not added to the digests until the last article added to the
thread is at least one month old (this is to ensure that the thread is dead
before adding it to the digests).

Send administrative mail to [e-mail].

-------------------------------------------------------

From: [e-mail] (Warren DeLano)
Subject: 680x0 Caches
Date: 8 Mar 92 04:55:25 GMT
Organization: Yale University

This may now be a FAQ, but what is the most fool-proof way to
flush the caches on a 680x0 machine?

Warren
[e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Glenn Austin)
Date: Mon, 9 Mar 92 09:47:23 PST
Organization: The Pit Lane


In article <[e-mail]> (comp.sys.mac.programmer), [e-mail] (Warren DeLano) writes:
> This may now be a FAQ, but what is the most fool-proof way to
> flush the caches on a 680x0 machine?

The BEST, most 100% foolproof way to flush the caches on the Mac (in asm
of course!):

    _FlushDataCache
    _FlushInstructionCache

===============================================================================
| Glenn L. Austin                | "Turn too soon, run out of room.           |
| Macintosh Wizard and           |    Turn too late, much better fate."       |
| Auto Racing Driver             |   -- Jim Russell Racing School Instructors |
| Usenet:  [e-mail] or [e-mail]    |
===============================================================================

---------------------------

From: [e-mail] (R. Munroe)
Subject: sprintf weirdness
Date: 8 Mar 92 05:32:12 GMT
Organization: UTCS Public Access


Just a little sprintf() strangeness:

Assume you have a pointer to a number of floats (actually any data type
will probably do) i.e. values[0] = 0.0 values[1] = 1.0 values[2] = 2.0.

Under THINK C 4, the following worked OK

char buffer[30];

sprintf (buffer, "%f %f %f", *values++, *values++, *values++);

Under THINK C 5, the values get reversed in the char buffer:

Should be:  0.0 1.0 2.0
But are: 2.0 1.0 0.0

>From what I understand, multiple incremention on the same line is
undefined by ANSI - so I guess it can't be called a bug.

sprintf (buffer, "%f %f %f", values[0], values[1], values[2]);

works just fine (so at least I have a work-around).

Just curious - why did it work OK under 4.0.x but
now doesn't work under 5.0.x?



- --
Bob Munroe                                : Internet:   [e-mail]
Technical Director                        : CompuServe: 71160,3455
TOPIX Computer Graphics + Animation, Inc. : AppleLink:  CDA0695

+++++++++++++++++++++++++++

From: [e-mail] (Matthias Ulrich Neeracher)
Organization: Integrated Systems Laboratory, ETH, Zurich
Date: Mon, 9 Mar 1992 09:28:28 GMT

In article <[e-mail]> [e-mail] (R. Munroe) writes:
>Just a little sprintf() strangeness:
>
>Assume you have a pointer to a number of floats (actually any data type
>will probably do) i.e. values[0] = 0.0 values[1] = 1.0 values[2] = 2.0.
>
>Under THINK C 4, the following worked OK
>char buffer[30];
>sprintf (buffer, "%f %f %f", *values++, *values++, *values++);

This depends on what you define as "OK" - 90% of the world's C programmers
would probably be very surprised with the result of this program.

>Under THINK C 5, the values get reversed in the char buffer:
>
>Should be:  0.0 1.0 2.0
>But are: 2.0 1.0 0.0
>
>From what I understand, multiple incremention on the same line is
>undefined by ANSI - so I guess it can't be called a bug.

Correct.

>sprintf (buffer, "%f %f %f", values[0], values[1], values[2]);
>
>works just fine (so at least I have a work-around).

NOt, you don't have a *workaround*, you have a *correct solution*.

>Just curious - why did it work OK under 4.0.x but
>now doesn't work under 5.0.x?

Easy, once you see it. 4.0.x evaluated arguments to sprintf() left-to-right,
like a Pascal compiler (I have this suspiction that TC 4.0.x was actually
Pascal in C clothing :-), while 5.0.x evaluates arguments right-to-left, like
most other C compilers. Why right-to-left ? Since for procedures with a
variable number of arguments to work, arguments *have* to be pushed on the
stack in right-to-left order, so that the called procedure always knows at what
stack offset to find the format string.

Hope this helped

Matthias

- -----
Matthias Neeracher                                   [e-mail]
 "You must have picked up that copy of Scarlett instead of Inside Mac
  when you tried to find the right call..." -- Keith Rollin

---------------------------

From: [e-mail] (Gregor Purdy)
Subject: Questions on THINK C Objects and Interrupts
Date: 8 Mar 92 15:08:11 GMT
Organization: University of Michigan EECS Dept., Ann Arbor, MI

Friends--

Does somebody out there know if it is OK for a THINK C virtual method to be
called at interrupt time? I've got a function that has a chance of being called
at interrupt time, and I want it to call a THINK C virtual method.

If not, can I use the Event Manager (or some pre-7.0 event stuff) to send my
self an event from that function (with a pointer to some data), which I'll
later get in my event loop, and then call my virtual method?

Thanks!

- --Gregor

- ------------------------------------------------------------------------------
Gregor N. Purdy                                               [e-mail]

greetings! I am a m@tating s_gnatu~e vrrus. Y*u can't resst hel#ing me +pread!
- ------------------------------------------------------------------------------

+++++++++++++++++++++++++++

From: [e-mail] (Phil Shapiro)
Date: 9 Mar 92 15:09:37 GMT
Organization: Symantec Corp.

In article <[e-mail]> [e-mail] (Gregor Purdy) writes:

   Does somebody out there know if it is OK for a THINK C virtual
   method to be called at interrupt time? I've got a function that has
   a chance of being called at interrupt time, and I want it to call a
   THINK C virtual method.

There shouldn't be any problem with this, provided that the virtual
method that you're calling is in a loaded segment, and that your
global data pointer (A5 or A4) is correct. The actual method dispatch
code is in the source file msg.c, if you want to check this out
yourself.

   If not, can I use the Event Manager (or some pre-7.0 event stuff)
   to send my self an event from that function (with a pointer to some
   data), which I'll later get in my event loop, and then call my
   virtual method?

According to IM, PostEvent is safe at interrupt time, but it's not a
good idea, since you can't tell which application you'll be posting
events to. If you're running under System 7 or MultiFinder, you could
post the event to another application's layer.

If the object dispatch doesn't work for you, you may want to just set
a global flag which your app's main loop can poll.

    -phil
- --
   Phil Shapiro                                   Software Engineer
   Language Products Group                     Symantec Corporation
           Internet: [e-mail]

---------------------------

From: [e-mail] (Peter Creath)
Subject: code overflow in Think C
Date: 8 Mar 92 06:31:40 GMT
Organization: Cube Technologies

Well, after being bitched at to read the manual, I felt it necessary
to track down the offending line and show you that I CAN'T break the
source file into smaller segments (yes, it's only one line that's
causing the problem):

unsigned long enc[4][4096], permenc[4][4096];

So I'm allocating 128k non-relocatable.  Bad programming practice,
sure, but how can I get around this error and still retain the array
use of these variables?  Can I just do this:

unsigned long enc[][], permenc[][];
&enc = NewPtr(65536L);
&permenc = NewPtr(65536L);

- ----------------------------------------------------------------------------
Peter Creath                 "When I was a boy I was told that anybody could
[e-mail]   become president; I'm beginning to believe it."
                                                           -- Clarence Darrow

+++++++++++++++++++++++++++

From: [e-mail] (Matthias Ulrich Neeracher)
Date: 9 Mar 92 09:35:43 GMT
Organization: Integrated Systems Laboratory, ETH, Zurich

In article <[e-mail]> [e-mail] (Peter Creath) writes:
>Well, after being bitched at to read the manual, I felt it necessary
>to track down the offending line and show you that I CAN'T break the
>source file into smaller segments (yes, it's only one line that's
>causing the problem):
>
>unsigned long enc[4][4096], permenc[4][4096];
>
>So I'm allocating 128k non-relocatable.  Bad programming practice,
>sure, but how can I get around this error and still retain the array
>use of these variables?  Can I just do this:
>
>unsigned long enc[][], permenc[][];
>&enc = NewPtr(65536L);
>&permenc = NewPtr(65536L);

No. The C compiler would have a hard time guessing the dimensions and the &enc
= ... is too avantgardist even for Algol. With the risk of forever destroying
my already dubious reputation on this esteemed forum, here is my untested,
uncompiled solution:

typedef unsigned long enctable[4][4096];

enctable * encp, * permencp;

encp      = (enctable *) NewPtr(sizeof(enctable));
permencp  = (enctable *) NewPtr(sizeof(enctable));

#define enc     (*encp)
#define permenc (*permencp)

Matthias

- -----
Matthias Neeracher                                   [e-mail]
   "One fine day in my odd past..." -- Pixies, _Planet of Sound_

---------------------------

From: [e-mail] (Lawrence D'Oliveiro, Waikato University)
Subject: "Procedural" (was Re: Suggestion to the Developers of Think C)
Date: 9 Mar 92 10:55:25 +1300
Organization: University of Waikato, Hamilton, New Zealand

In article <[e-mail]>, [e-mail] (Pete Gontier) writes:
> Well, that's not really much of an excuse, as long as the objects are
> a bag on the side of a procedural language, like C++.

Just a note on terminology here: object-oriented languages *are* a category of
procedural languages.

"Procedural" describes a language which lets you write "procedures", which
are rules for performing sequences of "actions", where an "action" is
something that causes a change in the machine state. Object "methods" are
just another kind of procedure.

The other kind of language is "functional", which only lets you write rules
for computing values from other values--there is no concept of change of
state.

Lawrence D'Oliveiro                       fone: [phone]
Computer Services Dept                     fax: [phone]
University of Waikato            electric mail: [e-mail]
Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+13:00

+++++++++++++++++++++++++++

From: [e-mail] (Matti Nykanen)
Date: 9 Mar 92 11:26:13 GMT

In <[e-mail]> [e-mail] (Lawrence D'Oliveiro, Waikato University) writes:

    :
>Just a note on terminology here: object-oriented languages *are* a category of
>procedural languages.
    :
>The other kind of language is "functional", which only lets you write rules
>for computing values from other values--there is no concept of change of
>state.

Don't forget the THIRD kind: Logic programming languages! :-)
Internet: [e-mail]  Department of Computer Science
Voice:    [phone]            University of Helsinki,Finland

---------------------------

From: [e-mail] (Aaron Giles)
Subject: Opening documents while the creator prog is running?
Date: 8 Mar 92 20:44:25 GMT
Organization: University of Chicago High Energy Physics


OK, this should be an easy question.  I've got a program (which needs
to be pre-System 7 compatible, so AppleEvents are out) which needs to
be able to respond when the user double-clicks one of its documents in
the Finder.  This is fairly straightforward when the program needs to
be launched; just use CountAppFiles(), GetAppFiles(), and
ClrAppFiles().  However, if the user tries to open a document while
the program is already running, the Finder does something to trick the
app into thinking the user selected Open (probably a Cmd-O event).
All fine and good, but I don't know how to determine the difference
between this situation and a normal Open operation.  I would assume
that a pointer to an AppFile structure or something similar would be
passed in the message field of the event, but I can't seem to figure
it out.  All I really need to know is how I get the file information,
what sort of structure it is, and how this event is different from the
standard Open event.

Thanks in advance,
Aaron
- -----
                     Aaron Giles -- [e-mail]
           "You can't have everything ... where would you put it?"

+++++++++++++++++++++++++++

From: [e-mail] (Matthias Ulrich Neeracher)
Date: 9 Mar 92 09:38:45 GMT
Organization: Integrated Systems Laboratory, ETH, Zurich

In article <[e-mail]> [e-mail] (Aaron Giles) writes:
>OK, this should be an easy question.  I've got a program (which needs
>to be pre-System 7 compatible, so AppleEvents are out) which needs to
>be able to respond when the user double-clicks one of its documents in
>the Finder.  This is fairly straightforward when the program needs to
>be launched; just use CountAppFiles(), GetAppFiles(), and
>ClrAppFiles().  However, if the user tries to open a document while
>the program is already running, the Finder does something to trick the
>app into thinking the user selected Open (probably a Cmd-O event).
>All fine and good, but I don't know how to determine the difference
>between this situation and a normal Open operation.

You shouldn't see any difference. The Multifinder tries its best to pretend to
your application that a normal open is happening.

Matthias

- -----
Matthias Neeracher                                   [e-mail]
   "There once was an Age of Reason, but we've progressed beyond it."
                                   -- Ayn Rand, _Atlas Shrugged_

+++++++++++++++++++++++++++

From: [e-mail] (Ed Kresch)
Date: 9 Mar 92 18:06:42 GMT
Organization: Villanova University

In article <[e-mail]> [e-mail] writes:
>
>OK, this should be an easy question.  I've got a program (which needs
>to be pre-System 7 compatible, so AppleEvents are out) which needs to
>be able to respond when the user double-clicks one of its documents in
>the Finder.  This is fairly straightforward when the program needs to
>be launched; just use CountAppFiles(), GetAppFiles(), and
>ClrAppFiles().  However, if the user tries to open a document while
>the program is already running, the Finder does something to trick the
>app into thinking the user selected Open (probably a Cmd-O event).
>All fine and good, but I don't know how to determine the difference
>between this situation and a normal Open operation.  I would assume
>that a pointer to an AppFile structure or something similar would be
>passed in the message field of the event, but I can't seem to figure
>it out.  All I really need to know is how I get the file information,
>what sort of structure it is, and how this event is different from the
>standard Open event.
>
>Thanks in advance,
>Aaron
>-----
>                     Aaron Giles -- [e-mail]
>           "You can't have everything ... where would you put it?"

Aaron,

When you double click on a document file while it's owner is running,
multifinder generates a mousedown event in the appropriate menu item.  It also
sets up a patch of some sort so that the next call to SFGetFile does not bring
up the normal dialog, but returns the information from the document file that
got the double click.  The point is that all this is done outside your program,
and there is no provision made by multifinder to allow your program to
distinguish this from a real mousedown event in the menu.  This is true in
system 7 as well as in the older systems when multifinder is used.

(For example, open any application that has a separate help file.  Pick one
that you know is well written, such as MacDraw, Word, etc.  Get back to the
finder leaving the application running, and double click on the help file.
The alert you get is a result of the inability of the application to
distinguish between these artificial mousedown events and real ones.  In
particular, upon receiving a command to open a document, the application calls
SFGetFile with a list of file types.  The help file is not included in this
list, since it is not a document that is expected to be opened.  Hence the
error message.)

There is a way around it; actually several.  I will give you the easiest one
I have found.  What you have to do is create a dummy menu entry that you never
allow to occur.  Here's what I mean.

In your resource file, you will have several menus, one of which is the file
menu.  Let's assume there are 6 items in this menu, the last of which is the
Quit command.  Create a 7th item; call it anything you want, I usually call
it MFGet (for multifinder get).  The end of the menu definition will look
like:

        "Quit",                             /*  6 */
            noIcon, "Q",    nomark, plain;
        "MFGet",                            /*  7 */
            noIcon, nokey,  nomark, plain

Also, in your resource file, the 'mstr' entries will now look like:

resource 'mstr' (100, purgeable)
{
    "File"
};

resource 'mstr' (101, purgeable)
{
    "Quit"
};

resource 'mstr' (102, purgeable)
{
    "File"
};

resource 'mstr' (103, purgeable)
{
    "MFGet"
};

In your initialization section of the program, set up the menus like this:

    MenuHandle      filemenu;
    char            mfget[12];
    .
    .
    .
    filemenu = GetMenu (fileId);
    GetItem (filemenu, 7, mfget);
    InsertMenu (filemenu, 0);
    .
    .
    .

Note that the MFGet entry is active at this time.

Then in your event loop, whenever there is a mousedown event in the menu bar,
you do the following:

    EventRecord     er;
    unsigned long   what
    .
    .
    .
    case inMenuBar:
        DelMenuItem (filemenu, 7);
        what = MenuSelect (er.where);
        /* Do menu stuff. In particular, if the menu ID is the file menu and
           the item is 7, call a subroutine such as MFGet ().*/
        AppendMenu (filemenu, mfget);
        break;
    .
    .
    .

In other words, you delete the MFGet item from the file menu before the menu
is drawn.  Then you add it back in after you are done.  Since the item is
deleted whenever the menu is displayed, it can NEVER be selected using the
mouse.  However, since multifinder generates this event artificially, it will
occur whenever you double click on an item owned by the application.

Your MFGet subroutine should only be called when the call is an artificial
one from the multifinder.  You can supply a different type list and avoid the
alert, or do whatever else you want in this subroutine.

This works with version <7 and multifinder; I have not had the opportunity to
test it with version 7 of the system.

I hope this is of use to you.

Ed Kresch

PS.  We have been having problems with our newsposter.  Sometimes the items
don't make it out of here.  I am posting this also, because I think others
might be interested.  Please let me know if you get the news item within a few
days so I can tell our system operator if the newsposter is working or not.
Thanks.

+++++++++++++++++++++++++++

From: [e-mail] (Jamie R. McCarthy)
Organization: Kalamazoo College
Date: Mon, 9 Mar 1992 19:57:31 GMT

[e-mail] (Ed Kresch) writes:
>
>(For example, open any application....  Pick one
>that you know is well written, such as ... Word ...

That was a joke, right?
- --
 Jamie McCarthy     Internet: [e-mail]     AppleLink: j.mccarthy
 Kzoo randomly kills all my mail;  if I don't acknowledge, try resending.

---------------------------

From: [e-mail] (David Putzolu)
Subject: Help! Declaring big array
Date: 9 Mar 92 07:01:53 GMT
Organization: Department of Computer Science, University of California, Davis

I'm trying to declare a big array in Think Pascal v. 4.0 like this:
bitMap : array[1..800,1..600] of boolean;
Think Pascal keeps telling me "available memory for variables at this
level has been exhausted". I've upped the stack space to 1meg, zone to
two, in vain hope that that would do it, since 800*600*1byte = 480k.
No luck. I've also tried declaring it dynamically (bm: ptr bitMap with
bitMap as a type, but then I can't remember how to access the
individual entries in the array). Has anyone run into a problem with
this before? And how do I solve it! Help!!!

| David M. A. Putzolu                  | [e-mail]                |
| Senior Undergraduate                 | op disclaimer(opinion : ptr mine)     |
| Computer Science and Psychology      |       Aiuto! Sono caduto e            |
| University of California at Davis    |         non posso alzarmi!            |

+++++++++++++++++++++++++++

From: [e-mail] (Matthew Hall)
Date: 9 Mar 92 16:49:08 GMT
Organization: Oberlin College Computer Science

Dear david -
    Due to the limitations of the segment manager, the size of any
segment must be less than 32k.  Global variables are included in the
size of a segment.  Therefore, even if you declared it as a packed
array   (in Think Pascal, this would be 1 bit per element instead of 8,
and if you are making a bitmap to copy to screen, you had better
use a packed array or your final image will be fairly strange looking),
you'd still have a 60k variable.  (Note - Think allows 64k segments in
it's environment, but when you build an app, you MUST have only
32k/segment after linking)
    How to do it in the heap?  Try This:

const imagewidth = 800;
      imageheight = 600;

var MyBitMap  : ptr;
    x,y       : Integer;
    offset    : LONGINT;

...
{INITIALIZATION}
MyBitMap:=newptr(imagewidth*imageheight div 8);
{Create a block in memory where there are 480,000 bits}
...

{Accessing x,y}
offset:=x+y*imagewidth;
{The first 800 bits are the top row, bits 801-1600 are the second row,etc}
BitSet(MyBitMap,Offset);
- -OR-
BitClr...
- -OR-
result:=BitTst...

Look up in IMI to make sure the format for BitSet is right.
Also, to make the long arithmatic work  (integers to longints) usually
you need to split up offset:=x+y*imagewidth into
offset:=y*imagewidth;
offset:=offset+x;

or declare x and y as LONGINT's

Then, if you wanted to copybits to screen, you could just set up a
bitmap where the baseaddr field = MyBitMap (rowbytes = 100, bounds =
(0,0,800,600) for the 800x600 case)

Hope this is of some help-
Matt Hall.
- --

<<[e-mail] OR
<<[e-mail]

This is just a beta version signature

---------------------------

From: [e-mail] (Chuck Shotton)
Subject: Looking for B-Tree/Data base source
Date: 9 Mar 1992 20:31:01 GMT
Organization: UTHSCH Academic Computing

Does anyone know where I can find PD or shareware C source for routines that
implement a simple indexed file system? I really only need one key, although
multiple keys would be nice.

In a similar vein, once upon a time, I remember seeing documentation about
an Apple-developed B Tree manager. Did it ever make it in as system software
or is it buried somewhere? I can't find any refs in IM I-VI, so my guess is
it doesn't exist. Yes?

Chuck

+++++++++++++++++++++++++++

From: [e-mail] (JohnC)
Date: 9 Mar 92 21:44:39 GMT
Organization: The Royal Society for Putting Things on Top of Other Things

In article <[e-mail]> [e-mail] (Chuck Shotton) writes:
>In a similar vein, once upon a time, I remember seeing documentation about
>an Apple-developed B Tree manager. Did it ever make it in as system software
>or is it buried somewhere? I can't find any refs in IM I-VI, so my guess is
>it doesn't exist. Yes?

It exists, since it is the basis of the HFS file system catalog and is also
used in the new Desktop DB and Desktop DF files.  There are even undocumented
traps that the operating system uses to manipulate the HFS B-trees.  The
reason Apple decided not to document the routines is that they were found to
be much too specific to the needs of the File Manager to be supportable as a
generalized B-tree system.


- --
John Cavallino                  |  EMail: [e-mail]
University of Chicago Hospitals |         [e-mail]
Office of Facilities Management | USMail: 5841 S. Maryland Ave, MC 0953
B0 f++ c+ g+ k s+(+) e+ h- pv   |         Chicago, IL  60637

---------------------------

From: [e-mail] (Kent Borg)
Subject: Letting Sleeping Powerbooks Lie
Organization: Camex Inc., Boston MA
Date: Tue, 03 Mar 1992 17:02:13 EST


It says (someplace buried in the manuals, I've never read them, so I
operate on hear-say) that when a Powerbook is in sleep mode it should
not be moved.  The explaination I heard is that the disk is not
parked.

That has me wondering, wouldn't it be pretty easy to write a faceless
background app that simply registers itself as being interested in
being told before a sleep, and have it park the disk?

The catch is figuring our how to be sure no one unparks the disk after
it has been parked, but playing with queue would probably do it.
(Yes, and getting in fights with other applications which think *they*
need to be last too.)

Finally, is this really necessary?  Is it the disk I need to worry
about?  Does the Quantum 80 disk park on powerdown?  (I plan to
upgrade to it from the original 20.)

P.S. And, can I safely store a floppy in the floppy drive?


- --
Kent Borg                            internet: [e-mail]   AOL: kent borg
                                            H:[phone]  W:[phone]
"Eating healthy beef is not healthful, the steer will take offense at you
chewing on his flanks."      -me

- -------------------------

From: [e-mail] (Juri Munkki)
Date: 4 Mar 92 20:11:44 GMT
Organization: Helsinki University of Technology, Finland

In article <[e-mail]> [e-mail] (Kent Borg) writes:
>It says (someplace buried in the manuals, I've never read them, so I
>operate on hear-say) that when a Powerbook is in sleep mode it should
>not be moved.  The explaination I heard is that the disk is not
>parked.
>
>That has me wondering, wouldn't it be pretty easy to write a faceless
>background app that simply registers itself as being interested in
>being told before a sleep, and have it park the disk?

I have heard to theories related to the "never move while sleeping"-rule.

The first one is that the disk is not parked, the other is that since
any keypress can turn the powerbook on, the disk will unpark itself when
it comes on and the computer will still be moving will the disk is
already rotating.

The second theory is certainly true and the the only thing you can do is
make your application wait for a password or some kind of confirmation
from the user when the machine wakes up. The simple parking application
that you proposed will not work alone.

I would be very surprised if the Conner disk drives didn't park automatically
when switched off. Of course, the truth often tends to be surprising.

   ____________________________________________________________________________
  / Juri Munkki        /  Helsinki University of Technology   /  Wind  / Project /
 / [e-mail]  /  Computing Center Macintosh Support  /  Surf  / Arashi  /
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

- -------------------------

From: [e-mail] (Quinn "The Eskimo!")
Organization: The University of Western Australia
Date: Thu, 5 Mar 1992 01:36:48 GMT

In article <[e-mail]>, [e-mail] (Juri Munkki) writes:
>
> I have heard to theories related to the "never move while sleeping"-rule.
>
> The first one is that the disk is not parked, the other is that since
> any keypress can turn the powerbook on, the disk will unpark itself when
> it comes on and the computer will still be moving will the disk is
> already rotating.

> The second theory is certainly true and the the only thing you can do is
> make your application wait for a password or some kind of confirmation
> from the user when the machine wakes up. The simple parking application
> that you proposed will not work alone.

The second theory may be true but it's also silly.  In that case us PB100
owners (where any key will wake the machine from Sleep *or* Shutdown) would
never be able to move our computers. (-:

I *never* shut my PB100 down and carry it *everywhere* with me on my bike.
In my own mind I'm convinced that the hard disk is as parked when I sleep
it as when I shut it down.  If not then I stand to lose a hard disk (it's
only 20MB -- I need to replace it anyway (-: ) and the data on it.  I guess
it's time to start backing up.

BTW Backing up a PowerBook is an especially good idea anyway.  So when
you get hit by a truck when walking across the road at least your valuable
data survives (-:

Quinn "The Eskimo!"   <[e-mail]>  "Real Coke, Diet .sig"
Department of Computer Science, The University of Western Australia
  --- Bicycling Cynic Extraordinair


- -------------------------

From: [e-mail] (Greg L. Anderson)
Date: 5 Mar 92 18:14:16 GMT
Organization: Apple Computer Inc., Cupertino, CA

In article <[e-mail]> [e-mail] (Kent Borg) writes:
>It says (someplace buried in the manuals, I've never read them, so I
>operate on hear-say) that when a Powerbook is in sleep mode it should
>not be moved.  The explaination I heard is that the disk is not
>parked.

The manuals are somewhat vague on the issue.  There's a place that says
that you should shut down your powerbook to transport it, but it never
explicitly states that it is unsafe to move the powerbook while it's
asleep (that is, there is no warning of possible data loss).  The manual
should be less vague--if someone somewhere in Apple thinks its a bad
idea to move a sleeping powerbook, they should have said so.  I couldn't
find anyone who held that view, though.

The word from the Powerbook engineering team is that the Powerbooks shut
down the hard disk exactly the same way weather you are shutting down
your PB or just putting it to sleep.  Therefore, if it is safe to move
your PB while it is off, it is safe to move it while it is asleep.

The don't-move-a-sleeping powerbook rumour originated from one of
Mac the Knife's articles in MacWeek, reprinted below:

- ----------------------------------------------------------------------
>From "Mac the Knife", MacWeek, 13 Jan 92, p. 194:

"Let Sleeping PowerBooks lie.

Reports of disturbingly high mortality rates of PowerBooks have been
noted.  Some of the problems have been traced to faulty designs or
less-than-adequate manufacturing techniques.  The Knife has discovered
that some of the failures can be traced to user ignorance of an unusual
and counterintuitive engineering feature of all PowerBooks.  Those few
souls who have actually read the documents accompanying their new
laptops know that you're not supposed to move a sleeping PowerBook.
Odd, isn't it?"
- ----------------------------------------------------------------------

I can't speak for the manufacturing quality of the PBs (other than to
say that I've only known one person who received a defective one, and
it was promptly fixed in warentee), but the warning about moving sleeping
powerbooks does appear to be foundless.

>Does the Quantum 80 disk park on powerdown?  (I plan to
>upgrade to it from the original 20.)

I'm no hard disk expert, but it is my understanding that HDs do
automatically park when they are powered down.

>P.S. And, can I safely store a floppy in the floppy drive?

That's a good question.  I don't know the answer, but I would be
warry of doing it because the floppy's shutter is open while it
is inserted in the disk, so it is more prone to contamination by
stray dirt particles.  I don't think there's any great danger of
data loss, though.
- --
=====================   ===========================   =====================
Greg Anderson           Apple Computer, Inc.            O    Ponnuki    O
Macintosh Bodhisattva   Developer Tools Engineering    O O  is  ideal  O O
[e-mail]       Apple Developer Suite           O     shape     O
=====================   ===========================   =====================

+++++++++++++++++++++++++++

From: [e-mail] (Kent Borg)
Organization: Camex Inc., Boston MA
Date: Mon, 09 Mar 1992 13:47:54 EST

In article <[e-mail]> [e-mail] (Quinn "The Eskimo!") writes:
>BTW Backing up a PowerBook is an especially good idea anyway.  So when
>you get hit by a truck when walking across the road at least your valuable
>data survives (-:

Seeing as how I am already in Powerbook withdrawl while they fix the
famous loose screen connector, I am starting to wonder wherther the
really dependent among us don't need a second notebook as a backup.
If I had had my computer for much more than a week when I had to part
with it think I would be in really bad shape right now.

As for techniques for abusing Powerbooks, I was coming out of the
grocery store the other day, with my computer in its normal bag
sitting in the babyseat of the shopping cart, rattleing and vibrating
along.  Then it occured to me that that was pretty stupid, so I slung
it over my shoulder.

- --
Kent Borg                            internet: [e-mail]   AOL: kent borg
                                            H:[phone]  W:[phone]
"Eating healthy beef is not healthful, the steer will take offense at you
chewing on his flanks."      -me

---------------------------

From: [e-mail] (Steve Jovanovic)
Subject: MPW C++ & Zortech C++ Info Wanted
Date: 5 Mar 92 22:56:22 GMT
Organization: Marquette University - Department MSCS

Hi Netters,

I'm interested in buying a C++ compiler for the Mac, and
I'd like to get some information on MPW & on Zortech.
First, is there any way to get MPW more cheaply than by
paying APDA the retail prices (I know they don't give
ed. disc.'s--why?)?  How much do MPW upgrades typically
cost?  Are there any quirks in the MPW C++ implementation?
Can MPW C++ be used as a generic C++ compiler--are any
libs provided to emulate a UNIX terminal?

Can Zortech C++ compile MacApp?  Is the current version
stable? (I've heard previous versions were buggy).  Does
anyone know if Zortech C++ is a temporary solution, until
Symantec can integrate it into THINK C, or will both be
marketed as separate applications?  I'm trying to get an
idea of whether or not it's "safe" to buy Zortech C++
without worrying that the product will be killed sometime
in the future.  Also, can it be purchased anywhere via
mail order?  The only place I've seen it advertised is in
Symantec's product catalogs, for $495 (including MPW Shell).
Does anyone have a phone # for Zortech?

Thanks a lot for your help!  I'll summarize all responses
in a future post.

steve jovanovic

PS Also, I'd appreciate any comments on the MPW Assembler.
Can you do inline assembly in Zortech?

+++++++++++++++++++++++++++

From: [e-mail] (Cory Kempf)
Date: 7 Mar 92 06:19:20 GMT
Organization: EnigamI, Inc., Nashua, NH


In article <[e-mail]> (comp.sys.mac.programmer), [e-mail] (Steve Jovanovic) writes:
>Hi Netters,
>
>I'm interested in buying a C++ compiler for the Mac, and
>I'd like to get some information on MPW & on Zortech.
>First, is there any way to get MPW more cheaply than by
>paying APDA the retail prices (I know they don't give
>ed. disc.'s--why?)?  How much do MPW upgrades typically
>cost?

I wish you luck.  At present, I would say that there are no *GOOD*
C++ compilers available for the Mac.

MPW C++ is a port of CFront 2.1.  AT&T's current release is 3.0, and
includes some new features that are not in the 2.0 release (like templates
& exceptions).

APDA is your only real source for MPW & C++, although you can often
get the MPW shell from other vendors who bundle it with other compilers
(Zortech, for one).

I am not sure how much upgrades usually cost outside of ETO.  If you
subscribe to ETO (e.g. buy MacApp, Pascal, etc.), it is $300/year.
Personally I am *VERY* dissatisfied with ETO.  The latest issue (ETO
6) looks like it was thrown together in about half an hour.  A really
low quality piece.  Very little new stuff on it, a couple of bug fixes,
and some parts were left out.  411, the main reason that *I* went
to the expence of ETO has not been upgraded yet, and *STILL* does
not include Inside Mac VI.  Oh yeah, if you are not an Apple Partner, tech
support is *NOT* available.

I am currently looking into the Zortech compiler, and will post a
summary next week or so, but so far, the answers that I have gotten
back are not good.

>  Are there any quirks in the MPW C++ implementation?
>Can MPW C++ be used as a generic C++ compiler--are any
>libs provided to emulate a UNIX terminal?

Well, volitile is *NOT* implimented (it is implimented in the C++
compiler, but not in the C compiler (e.g. Apple's C is NOT ANSI!).
Like I said, it is only up to the 2.1 release of CFront, not 3.0.
They do include two options for standard io type interaction, you
can write a shell tool, which is more or less like any other unix
app, or you can write an SIOW application, which is an application
that has a StdIO window.  I don't think that curses are suppported
though, but I have never looked.

>Can Zortech C++ compile MacApp?

from what I can tell, no.

+C


- -------------------------------------------------------------
Cory Kempf                    EnigamI, Inc.
[e-mail]           ...!decvax!enigami!cory

---------------------------

From: [e-mail] (W. Frank Price)
Subject: CTB/System 7 popup menu bug
Date: 6 Mar 92 03:36:23 GMT
Organization: Harvey Mudd College

I've been encountering a bug in the System 7 popupmenu CDEF stuff that
draws the popup menu incorrectly in Geneva 12 if you setit to Geneva 9.
It is quite repeatable on any system, and happens after running Mac Write
II.  It works fine before you run that program.  Apparently seveal
Microsoft applications also cause this to happen.  Anyone can see this
ocur by running MacWrite II and then pulling down a popup menu in a comm
toolbox application.  I am trying to write a CDEF to temporarily get
around this, but in order to do that, I have to know what variable is
getting mucked.  It must be some low memory global that is getting trashed
by MWII, but nobody seems to know.  Apple just says "the bug will be fixed
in a future release of the system software."  Great, but the real world
isn't on their rather protracted schedule.

Is anyone encountering this or able to offer some assistance on which
variable(s) are in question?

+++++++++++++++++++++++++++

From: [e-mail] (Scott Lindsey)
Date: 6 Mar 92 23:54:50 GMT
Organization: Claris Corporation

In article <[e-mail]>, [e-mail] (W. Frank Price) writes:
>
> I've been encountering a bug in the System 7 popupmenu CDEF stuff that
> draws the popup menu incorrectly in Geneva 12 if you setit to Geneva 9.
> It is quite repeatable on any system, and happens after running Mac Write
> II.  It works fine before you run that program.  Apparently seveal
> Microsoft applications also cause this to happen.
[...]
> Is anyone encountering this or able to offer some assistance on which
> variable(s) are in question?

I used TMON to dump out 0-$2000, and compared before and after and here's the likely
suspects.  However, I don't have a copy of MWII source right now (and I certainly
don't have any MicroSoft source) to see if it's direct manipulation of any of these.
Most of these aren't documented in IM I-VI or the tech notes.

ClarisWorks seems to fix the problem if run after MWII has been launched, but not
if MWII is launched while ClarisWorks is still running.
A likely suspect seems to be MWII's MDEF (Do the MicroSoft apps in question have
their own MDEF's?), particularly the WYSIWYG Fonts menu.  MacTerminal doesn't have
an MDEF (or a fonts menu), and the problem doesn't clear up on it.  ClarisWorks has
an MDEF similar to MWII's (but not exactly the same) which might explain why it
fixes it.  Possibly calls to GetFontInfo from the MDEF modify one of these when the
pop-up CDEF doesn't expect it to change, or expects that it be some standard value.
Particularly suspect are CurFMInput and CurFMSize.  Maybe an assumption like "if
CurFMInput is non-zero (not the system font) then I can use those globals because
it's left around from when I asked about Geneva 9, otherwise, it's the system font,
which I know isn't Geneva 9, so I'd better check everything" was made.

"dump" was made while the bug was evident;  "dump2" after it had been "fixed";
neither were made while the machine was in any particular consistent state.

Nonmatching lines (File "dump"; Line 599; File "dump2"; Line 599)
 599    00000903:      TFondStateU  : $20

 599    00000903:      TFondStateU  : $60

Nonmatching lines (File "dump"; Line 623:626; File "dump2"; Line 623:626)
 623    00000986:      TGotStrikeU  : $60
 624    00000987:  TFMDefaultSizeU  : $0C
 625    00000988:     TCurFMInputU  : 0004
 626    0000098A:      TCurFMSizeU  : $000C

 623    00000986:      TGotStrikeU  : $F0
 624    00000987:  TFMDefaultSizeU  : $0C
 625    00000988:     TCurFMInputU  : 7F0D
 626    0000098A:      TCurFMSizeU  : $0009

Nonmatching lines (File "dump"; Line 630:633; File "dump2"; Line 630:633)
 630    00000990:     TCurFMNumerU  : $00010001
 631    00000994:     TCurFMDenomU  : $00010001
 632    00000998:      TFOutErrorU  : $0000
 633    0000099A: TFOutFontHandleU  : $0013D594

 630    00000990:     TCurFMNumerU  : $00090009
 631    00000994:     TCurFMDenomU  : $00090009
 632    00000998:      TFOutErrorU  : $0000
 633    0000099A: TFOutFontHandleU  : $00011584

Nonmatching lines (File "dump"; Line 641:643; File "dump2"; Line 641:643)
 641    000009A5:     TFOutAscentU  : $0C
 642    000009A6:    TFOutDescentU  : $03
 643    000009A7:     TFOutWidMaxU  : $07

 641    000009A5:     TFOutAscentU  : $09
 642    000009A6:    TFOutDescentU  : $02
 643    000009A7:     TFOutWidMaxU  : $06

Nonmatching lines (File "dump"; Line 783:784; File "dump2"; Line 783:784)
 783    00000BC2:   TLastFONDU  : $001060D4
 784    00000BC6:     TFONDIDU  : $0004

 783    00000BC2:   TLastFONDU  : $00125158
 784    00000BC6:     TFONDIDU  : $7F0D


- --
Scott Lindsey <[e-mail]>

---------------------------

End of C.S.M.P. Digest
**********************